✅ Automated recommendation: APPROVE

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Summary

This PR centralizes visible issue filtering across Board, Projects, and the Issues API route using a shared helper function (buildVisibleIssueWhere). The implementation addresses issue #196 by ensuring consistent Done retention behavior (7-day default) across all views.

Change-by-Change Findings

src/lib/issue-filters.ts (+34 lines)

• Added VisibleIssueWhereOptions interface with includeClosed and doneRetentionDays options
• Added DEFAULT_DONE_RETENTION_DAYS = 7 constant
• Added getDoneRetentionDays() that reads DISPATCH_DONE_RETENTION_DAYS env var, defaults to 7, clamps invalid values (0, negative, NaN) to default
• Added buildVisibleIssueWhere(where, options?) that mutates the where clause in-place:
  • When includeClosed=true: returns early, no state filter (shows all issues)
  • Default behavior: sets where.OR with open issues + recently closed Done issues within retention window
• Implementation correctly handles the OR filter structure with { state: "open" } and { state: "closed", labels: { has: "status/done" }, closedAt: { gte: cutoff } }

src/app/api/issues/route.ts (+2, -5 lines)

• Key fix: Replaced 5-line inline filtering (if (includeClosed !== "true") { where.state = "open" }) with buildVisibleIssueWhere(where, { includeClosed: includeClosed === "true" })
• This changes the API route from open-only by default to open + recently closed Done issues with 7-day retention, matching Board/Projects behavior

src/app/board/page.tsx (+3, -24 lines)

• Removed inline DONE_RETENTION_DAYS constant and getDoneRetentionCutoff() function
• Replaced 15-line inline OR filter logic with single buildVisibleIssueWhere(where, { includeClosed }) call
• Updated static string message to use getDoneRetentionDays() for dynamic retention day display

src/app/projects/page.tsx (+5, -20 lines)

• Removed inline DONE_RETENTION_DAYS constant and getDoneRetentionCutoff() function
• Replaced 15-line inline OR filter with buildVisibleIssueWhere(where) call
• Now uses shared helper instead of duplicate inline logic

.env.example (+3 lines)

• Added documented DISPATCH_DONE_RETENTION_DAYS env var with default value of 7

src/lib/issue-filters.test.ts (+113 lines)

• Added 6 tests for buildVisibleIssueWhere: default 7-day retention, includeClosed=true behavior, custom doneRetentionDays option, env var respect, preserves existing where clauses
• Added 3 tests for getDoneRetentionDays: default 7, env var respect, invalid value clamping (NaN, 0, negative)
• Tests properly reset process.env in beforeEach blocks

src/app/api/issues/route.test.ts (new, +148 lines)

• 14 tests covering default filtering, includeClosed param, env var respect, all filter params (repo, agent, owner, priority, project, decomposed), ordering, includes, combined filters, response shape, error handling
• Tests verify the actual Prisma findMany call arguments via mock assertions

Standards Compliance

✅ No agent-specific names — Code uses generic patterns; no hardcoded agent identifiers
✅ TypeScript types — VisibleIssueWhereOptions interface exported, proper typing throughout
✅ Error handling — API route has try/catch with 500 error response (confirmed in route.test.ts)
✅ Validation — getDoneRetentionDays() validates and clamps invalid env values
✅ Environment variables — Follows repository pattern for optional config with sensible defaults
✅ Tests — Use vitest (repository standard), include error path coverage, reset mocks between tests
✅ No secrets in code — No .env files committed, no token logging

Linked Issue Fit

Issue #196 acceptance criteria comparison:

Implementation matches suggested approach from issue: shared helper function buildVisibleIssueWhere({ includeClosed, doneRetentionDays, filters }) with env var support.

Tool Harness Findings

No tool requests were executed. The PR is a refactoring change (no image updates, no version changes) that can be fully validated through code review of the diff and test coverage provided.

Unknowns / Needs Verification

• Test count (938): PR claims "All 938 tests pass" — this was not independently verified as tool harness ran in plan-only mode with no requests executed. The test suite size (+261 test lines across two files) is substantial and covers the new functionality.

• CI validation: Standard GitHub Actions workflow should run lint, typecheck, tests, and build automatically. The PR body states these are clean but this reviewer cannot confirm without execution.